INTERACTIVE INVOICER INTERFACE 



Background of the Invention 

(1) Field of the Invention 

The present invention relates generally to automated billing systems and, more 
particularly, to an automated electronic invoicing and payment consolidation system 
for providing remote customer review of billing information from at least two 
invoicers. 

(2) Description of the Prior Art 

Invoicing and payment collection has always been a very labor intensive and 
paper intensive process. Typically, the process has involved an invoicer, usually a 
business, who prepares an invoice detailing the goods and services provided and the 
charges therefor. The invoice is mailed to a customer who verifies the correctness of 
the invoice and returns a payment coupon of some type along with a paper check to 
the invoicer. The invoicer then submits the paper check to its bank for payment 
through; for example, the Automated Clearing House (ACH) network. Other similar 
payment systems include writing a credit card number, endorsing and 
preauthorization to draft an account on a monthly basis up to preset limits, such as 
regularly paying utility bills from a checking account. 

With the advent of the Internet, invoicers have expressed the desire for the 
time-honored process of paper billing and payment to be automated. One approach 
that is somewhat popular is electronic bill payment services. In this approach, 
customers receive an invoice that is presented by paper and a separate payment 
service, often branded by a bank, allows payment to be pushed to the invoicer. The 
customer takes their paper bill and logs on to an Internet-based service that receives 
payment instructions resulting in either an electronic payment or, more often, a paper 
draft that is mailed on behalf of the customer. 

This service, while in some ways convenient to the customer, can result in 
errors, as payment is often received with data irregularities that prevent accurate 
posting. Further, the customer must still handle the bills in much the same way as 
before and must actually give instructions to pay earlier, since 3-5 days may be 
required to perform the payment process. Checkfree is the largest provider of this 
type of service. 
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Most industry observers have noted that a more reliable and efficient 
processing for invoicing is for the customer to receive an electronic version of the 
invoice with an opportunity to make an electronic payment or dispute individual line 
items in the same session. To this end, a number of different approaches are known. 
5 One approach is direct invoice presentment and payment as described in US 

Patent Nos. 6,044,362 and co-pending US Patent Application Serial No. 09/535,334. 
This invention established a direct link between customer and invoicer for the 
presentation and payment of electronic invoices. This technique is preferable to most 
invoicers in that it provides the strongest branding, flexibility, clarity in support 

10 operations, lowest cost and allows the invoicer to maintain current banking relations. 
However, one disadvantage of this approach is that the customer must access multiple 
accounts, each with different password and sign up requirements. 

Another approach is consolidated bill presentment, whereby invoicers send 
their raw billing data to a central service that consolidates the data into a list of bills to 

1 5 display to customers of the companies participating with the service. Companies send 
their data to the consolidating service in a "Push Model." This is also referred to as 
"thick consolidation," as a large database is created, which combines data from many 
billers into a central service. Such electronic systems are described in U.S. Patent 
Nos. 5,383,1 13, issued to Kight et al.; 5,649,1 17 and 5,956,700 issued to Landry; 

20 5,283,829, issued to Anderson et al; 5,220,501, issued to Lawlor et al.; and 

5,465,206, issued to Hilt et al., the disclosures of which are hereby incorporated by 
reference in their entireties. 

In these electronic billing and payment consolidation systems, the third party's 
website is the central point of access as customers login to access bills. Often, the 

25 third party consolidation service may allow, for a fee, a different organization to 

brand the page that the invoicers' customers might access. For example, Company A 
could send its raw billing data to a third party consolidation service and when the 
customers of Company A's access their invoices, the page would be branded by a 
bank or an Internet portal. While the invoice presented to the customer would still 

30 include Company A's logo, branding of the overall service, enrollment, banner ads, 
and the service relationship would be controlled by the third party consolidation 
service and its licensees. 
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This type of service offers some advantages to invoicers and customers alike. 
For invoicers, this approach is easy to adopt for a pilot as the service is outsourced 
and the invoicer need only provide raw billing files to start the process. Also, for the 
customers, enrollment and password management is simplified and bill review 
5 operations can be more efficient, as customers can access one website to see multiple 
invoices. Although these systems appear to streamline the process, they, in fact, may 
add a great deal of complexity and no small amount of expense to the process: 

• First, there are many consolidation services and customers will have distinct 

10 preferences in some cases. However, many invoicers feel they are compelled by 

the marketplace to work with multiple consolidation services to get their bills out 
to as many places as possible for added customer convenience. Since raw billing 
data and other reference information must be sent or pushed to different services, 
extensive operational investments must be made. Specifically, data formats are 

1 5 often different and the invoicer' s internal support team must understand the 

nuances of each service. Also, different banking interfaces and payment posting 
routines can cause complexity in supporting multiple consolidators. Thus, the 
potential for cost savings of electronic presentment and payment can often be lost 
in the complexity. 

20 • Second, the service fees charged per invoice by consolidation service providers 
are often high and, once again, the potential for cost savings can be lost. 

• Third, branding is often no longer controlled by the invoicer, but is controlled by 
the third party consolidation service or by whomever purchases the right to re- 
brand from the third party consolidation service. 

25 • Fourth, the invoicer often looses control as to which parties are able to present the 
invoicer' s invoices. In fact, a company that is deemed competitive by the invoicer 
might facilitate a bill consolidation service that includes bills of the invoicer by 
virtue of a business relationship with the third party consolidation service. As an 
example, a mortgage bill from a private financing company might be reviewed by 

30 a customer at a third party site re-branded by a competitor bank that also offers 

mortgage re-financing online through the bank. The banner ads presented on the 
bank's behalf might result in a loss of the private financing company's customer 
visiting that third party site. 
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• Fifth, data sent to the third party is time sensitive. Subsequent changes of 
customer data at the invoicer are not reflected or updated in the electronic invoice 
presented. The electronic bill consolidation service can quickly become 
unsynchronized with data at the invoicer causing customer confusion that can lead 

5 to expensive user support. 

• Sixth, customer care is difficult in this environment since relationships may be 
confused for troubleshooting and support. Problems might result from 
reformatting or biller and there will be confusion as to the cause and remedy of 
the problem 

10 • Seventh, there is no workable approach to "consolidate consolidators." That is, it 
is unlikely that a single third party consolidation service will acquire data from 
every invoicer of a specific individual service customer. The competitive nature 
of the market makes it almost certain that an individual will need to log on to 
more than a single, third party site to review all of their invoices since no single 

15 third party consolidator is likely to have enrolled all of a specific individual 

service customer's invoicers. 

Still another technique for electronic bill presentment and payment is "thin 
consolidation/' In this model, only summary data is sent or pushed to the central 
20 consolidation service. As customers login to see a list of bills and payment options, 
they can select a navigation option that links them to detailed information located at 
the invoicer during sessions managed and controlled by the central, third party 
service. While this approach provides more control to the invoicer over important 
customer operations, it also has significant drawbacks: 

25 

• First, the central service largely limits the processing and usage options at the 
invoicer. For example, registration or enrollment in the service starts with the 
central service and invoicers do not always get full disclosure of what information 
was supplied at registration. Requiring enrollment at the consolidation service in 

30 many ways passes "ownership" of the customer to the third party consolidation 

service, rather than the invoicer. 
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• Second, business relationships for payment are dictated by the central service in 
these models- not at the invoicer. Payment is required through the third party 
consolidation service. 

• Third, disputes regarding payment are accomplished at the third party 

5 consolidator, creating a difficult process of communication, customer care and 

reconciliation for the invoicer. 

• Fourth, invoicers lose branding opportunities and cannot control whom the third 
party consolidation service can allow to re-brand the service. The consolidated 
nature of the data in the service makes it difficult to provide an environment 

10 whereby its invoice summary could not be displayed by a re-branding portal that 

may advertise a competitor. 

• Fifth, thin consolidation, as currently practiced, does not allow the customer to 
login to see invoice detail directly at the biller, but must always start with the 
consolidation service. 

15 

An invoicing system should allow invoicers to maintain their direct relationship 
with customers, yet allows the convenience of simplifying access across multiple 
sites. Also, customers should be able to easily see a list of summary data from 
invoices and link to invoicers' sites without the biller giving up control over the 

20 process. There also needs to be a simple approach whereby an invoicer can "write 
once" for multiple publication by alternate access sites. Such a process would allow 
the invoicer to put summary data for inclusion in a list of bills, and then allow 
secondary presentment points to retrieve the data (Pull Model) from the invoicer's site 
for presentment. Invoicers should have means to make their summary data available 

25 for the consolidators to retrieve dynamically, rather than the current "push" 
consolidation technique, to ensure the most current data. 

This requires consolidation techniques that preserve the branding of the biller, the 
customer care relationship, the choice of financial partners and the marketing 
opportunities of the invoicer. Such a system should not require that the provider of 

30 valuable content - in this case invoicers providing bill summary or full, electronic 
billing data - to have to pay a third party to take the valuable content - only for that 
party to sell to additional parties down the line. The system should allow indexing 
across multiple direct sites that provides convenience to customers without removing 
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important operations and control considerations from invoicers. Invoicers should also 
be able to select which sites could present bill and payment summaries, purchase 
orders, shipping documents, etc. Data should be provided in number of techniques to 
simplify retrieval and inclusion into other bill lists. The preferred embodiment 
5 includes provision of graphic images that are retrieved by the customer's browser as 
well as XML strings that are passed to secondary presentment partners. 

Thus, there exists a need for a simple, straight forward system and method of 
automated electronic invoicing and payment that directly involves the invoicer and 
the customer while, at the same time, would allow customers to visit a invoicer' s 

1 0 website through a single portal or bank site and review a summary of all of their bills 
and then visit invoicers' Web sites. Such a system would permit presentation of truly 
current data to the customer while, at the same time, provide timely payment to the 
invoicer. Also, since there is no need for a third party payment engine, the invoicer 
gains both lower cost per transaction and can control "branding" at the URL or portal 

1 5 rather than having to show the banner ads of a third party provider. 

Summary of the Invention 

The present invention is directed to an automated electronic invoicing and 
payment consolidation system for providing remote customer review of billing 
20 information from at least two invoicers. In the preferred embodiment, the system 
includes three primary components: a consolidated invoicer interface; a remote 
customer interface for accessing the consolidated invoicer interface; and a payment 
engine. 

f In the preferred embodiment, the consolidated invoicer interface provides at 
25 least one access point to each of the invoicers; sets the access point of each of the 

invoicers for at least one customer; authenticates each of the customers; and 

automatically requests account information directly from each of the invoicers. 

Also, in the preferred embodiment, the payment engine sends the customer 

payment instructions from the customer directly to each of the invoicers. The 
30 preferred payment engine is set forth in commonly owned U.S. Patent No. 6,044,362, 

issued March 28, 2000 and co-pending U.S. Patent Application Serial No. 

09/535,334, now U.S. Patent No. , issued , , which are 

hereby incorporated by reference in their entirety. 
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The payment engine includes: invoice presentation electronics adapted to 
present customer billing data for customer review and to request payment instructions 
relating to automated billing to the customer; and a remote electronic customer 
authorization interface adapted to: (i) receive the customer billing data for customer 
5 review and the request for payment instructions from the invoice presentation 
electronics; (ii) provide the customer billing data and the request for payment 
instructions to the customer; (iii) receive customer payment instructions from the 
customer in response to the request for payment instructions; and (iv) transmit the 
customer payment instructions from the customer directly to each of the invoicers, the 

10 payment instructions including at least an invoice account number and an associated 
customer payment account. 

Thus, in the preferred embodiment, customer data is pulled from invoicer's 
sites through a component installed on each invoicer's web sites. This component 
reads invoicer's data, packages it and fulfills requests made to the portal by the 

15 customer. 

Accordingly, one aspect of the present invention is to provide an automated 
electronic invoicing and payment consolidation system for providing remote customer 
review of customer account information from at least two invoicers. The system 
includes: a consolidated invoicer interface wherein the invoicer interface includes: (i) 

20 at least one access point to each of the invoicers; (ii) means for setting the access 
point of each of the invoicers for at least one customer; and (iii) means for 
authentication of each of the customers; and a remote customer interface for accessing 
the consolidated invoicer interface. 

Another aspect of the present invention is to provide a consolidated invoicer 

25 interface for an automated electronic invoicing and payment system for providing 

remote customer review of customer account information from at least two invoicers. 
The system includes: at least one access point to each of the invoicers; means for 
setting the access point of each of the invoicers for at least one customer; means for 
authentication of each of the customers; and means for automatically requesting 

30 account information for said customers directly from each of the invoicers. 

Still another aspect of the present invention is to provide an automated 
electronic invoicing and payment consolidation system for providing remote customer 
review of customer information from at least two invoicers. The system includes: a 
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consolidated invoicer interface wherein the invoicer interface includes: (i) at least one 
access point to each of the invoicers; (ii) means for setting the access point of each of 
the invoicers for at least one customer; (iii) means for authentication of each of the 
customers; and (iv) means for automatically requesting account information for said 
5 customers directly from each of the invoicers; a remote customer interface for 
accessing the consolidated invoicer interface; and a payment engine wherein the 
customer payment instructions are sent from the customer directly to each of the 
invoicers, the payment engine including: invoice presentation electronics adapted to 
present customer billing data for customer review and to request payment instructions 

1 0 relating to automated billing to the customer; and a remote electronic customer 

authorization interface adapted to: (i) receive the customer billing data for customer 
review and the request for payment instructions from the invoice presentation 
electronics; (ii) provide the customer billing data and the request for payment 
instructions to the customer; (iii) receive customer payment instructions from the 

1 5 customer in response to the request for payment instructions; and (iv) transmit the 

customer payment instructions from the customer directly to each of the invoicers, the 
payment instructions including at least an invoice account number and an associated 
customer payment account. 

These and other aspects of the present invention will become apparent to those 

20 skilled in the art after a reading of the following description of the preferred 
embodiment when considered with the drawings. 

Brief Description of the Drawings 

FIGURE 101 is a schematic overall representation of a method for providing 
25 electronic invoice summaries and paying performed according to present invention; 

FIGURE 102 is a functional representation of the "thin portal" model for 
electronic invoicing and paying performed according to present invention; 

FIGURE 103 is a schematic representation of a "thin portal" electronic 
invoicing and payment system constructed according to the present invention; 
30 FIGURE 104 is a detailed functional representation of the enrollment process 

at a portal for electronic invoicing and paying performed according to present 
invention; 
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FIGURE 105 is a detailed functional representation of the 
invoicing/presentation process at a portal for electronic invoicing and paying 
performed according to present invention; 

FIGURE 106 is a detailed functional representation of the summary 
5 server/payment process of the method for electronic invoicing and paying performed 
according to present invention; 

FIGURE 107 is an example of a suitable data model of the "thin portal" 
electronic invoicing and payment system constructed according to the present 
invention; 

10 FIGURE 108 is a functional representation of a "thick portal" electronic 

invoicing and payment system constructed according to the present invention; 

FIGURE 109 is a schematic representation of the enrollment portion of an 

automated electronic invoicing and payment consolidation system constructed 

according to present invention; 
1 5 FIGURE 1 1 0 is a schematic representation of the dynamic display portion of 

an automated electronic invoicing and payment consolidation system constructed 

according to present invention; 

FIGURE 1 1 1 is a schematic representation of a prior art invoicing payment 

engine system; 

20 FIGURE 1 1 2 is a schematic representation of a preferred payment engine 

method for electronic invoicing and paying performed according to present invention; 
and 

FIGURES 113A and 113B are schematic representations of a preferred 
payment engine electronic invoicing and payment system constructed according to the 
25 present invention. 

Detailed Description of the Preferred Embodiments 

In the following description, like reference characters designate like or 
corresponding parts throughout the several views. Also in the following description, 
30 it is to be understood that such terms as "forward," "rearward," "left," "right," 

"upwardly," "downwardly," and the like are words of convenience and are not to be 
construed as limiting terms. 
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As best seen in Figure 101, there is shown an overall schematic view of a 
dynamic consolidation model, generally designated 210, constructed according to the 
present invention. The basic components are the customer Internet interface 212; the 
summary agent portal 214; and at least two invoicers 216. In the preferred 
5 embodiment, the invention also includes a payment engine 220, which is the interface 
between the customer Internet interface 212 and the invoicers 216. In the preferred 
embodiment, such a payment engine is described in U.S. Patent No. 6,044,362, issued 
March 28, 2000, which again is hereby incorporated by reference in its entirety. 

Looking first at the overall dynamic consolidation model 210, each of the 

10 invoicers 216 and the summary agent 214 first setup an initial agreement 222. The 
agreement would include at a minimum, URLs for access, summary agent name, and 
other elements to be used for validation. Additionally, an invoicer and a portal may 
also agree upon a web page to be used for customer enrollment. On this enrollment 
page, the invoicer would specify elements required for validation of the customer, e.g. 

1 5 username, password, account and pin number. These elements would in turn be used 
by the summary agent and invoicer when retrieving data or in validating a transfer to 
the invoicer site. After the summary agent and biller enrollment is complete, 
customer 212 may first enroll at the summary agent portal 214, then be transferred for 
enrollment at the invoicer' s site 216. 

20 In an alternative embodiment, the customer could enroll with the invoicer first 

and enter relevant customer information. After enrollment is complete at the invoicer, 
the customer could then specify that it would like to have its bills displayed at a 
number of portals. Thus, while the preferred embodiment for customer enrollment is 
to start with the portal and pass enrollment to the invoicer, enrollment may also begin 

25 at the invoicer and the invoicer may provide a list of portals that the invoicer has 
agreements with from which the customer could then select those portals where the 
customer would like to have its bills displayed. 

While customer enrollment is shown in Figure 101 as being two separate 
actions 224, 225, the summary agent portal 214 could be authorized to complete the 

30 enrollment setup between the customer 212 and invoicer 216 as the customer's agent. 
Authentication information may also be 'generated and stored at the portal and then 
also subsequently stored at the invoicer. When the customer begins to request 
summary information, the summary agent upon the request first validates the 
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customer. Then the request is sent to the invoicer and the invoicer verifies the 
customer requests is actually for an account that they currently have and there is a 
valid account password pair that they can then return back to the portal. 

Also, during the enrollment between the summary agent and invoicer, the 

5 invoicer could also specify relevant URLs for the customer to view detailed invoice 
information. Thus, when the customer chooses to view detailed information at the 
summary agent, they could be passed to a site that has been provided by the invoicer, 
the customer would then be taken to that particular invoicer site based upon the URL 
that the invoicer has specified. 

10 In operation, customer 212 sends a request 226 to summary agent portal 214 to 

show all outstanding bills. In response, summary agent portal 214 sends a request to 
each invoicer site 216 to deliver bill summary information to summary agent portal 
214 for the selected customer 212 along line 230. Summary agent portal 214 then 
delivers the consolidated bill summaries to customer 212 via line 232. When, as in 

1 5 the preferred embodiment, a payment engine 220 is in place, the customer 212 may 
view detailed invoicer information along line 234 and, in addition, may also modify 
payment arrangements along line 236 as discussed in detail in commonly owned U.S. 
Patent No. 6,044,362. At this point, the customer can actually authorize payment and 
the invoicer will send and request to receive funds directly from the customer's bank, 

20 without the need for a third party consolidator. 

The actual operation of the present invention may also be understood 
functionally by referring to Figure 102. As can be seen, summary agent portal 214 
establishes initial agreement with the invoicer, which includes both allowing the 
invoicer to visit the portal site and sign up the invoicer site to provide ultimate access 

25 for the customer. Invoicers at this time can also setup the access security between the 
sites and what information will be available to the customer at the summary agent 
portal 214. 

In addition, summary agent portal 214 allows the customers 212 to enroll and 
select the invoicers to be displayed and passes control to the invoicer for enrollment 
30 of a particular customer. The portal accepts a unique username and password 

generated by the invoicer, stores each of these unique username and passwords for 
each customer account. In the preferred embodiment, these pairs are saved at the 
summary agent portal for each customer 212 and do not have to be reentered each 
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time a customer 212 logs in to the summary agent portal 214. The summary agent 
portal 214 also allows the customer to configure his preferences for the portal display 
at the summary agent portal Web page. 

Where the customer is allowed to configure his preferences for the portal 
display, this would be a "portal configurator" where the customer is actually able to 
specify user interface display changes based upon certain events. One example may 
be if the bill is late or past due, change the colors by which the bills being shown at 
the portal site, which gives the customer some indication of a late payment or a late 
bill that is about to occur, or the customer may want to specify a particular amount 
that the customer wants to have highlighted if a bill exceeds a certain amount within 
the summary, things along those nature, would be determined as preferences by the 
customer. 

The summary agent portal 214 pulls and displays the bill summary 
information from the invoicer site 216. The portal sends the customer request directly 
to the invoicer site and sends the request by first transmitting authentication 
information, for example an encrypted name/password pair or a security token, to the 
invoicer 5 s site and then receiving summary data from the invoicer or from a summary 
server at the invoicer' s site. At this time, using a payment engine, such as described 
in commonly owned U.S. Patent No. 6,044,362, the customer 212 can also go directly 
to invoicer 216 and execute a payment transaction. 

In addition to the above functions, summary agent portal 214 may allow the 
customer to indicate that they have reviewed the invoice or download the payment 
summary data information on the screen. In addition, the summary agent portal may 
process and display transmission error messages which the customer may then 
attempt to correct. The summary agent portal 214 also may be used to display banner 
ads to generate additional revenue for the summary agent portal owner. Finally, the 
summary agent portal may also allow the customer to unenroll from one or more 
invoicers in the event the customer no longer wishes to use the summary agent portal, 
or no longer has an account with a specified previously enrolled invoicer. 

The invoicer' s site 216 has complimentary functions to the summary agent 
portal 214. The invoicer site 216 operates to establish an agreement with summary 
agent portal 214 including allowing a portal administrator to directly visit a invoicer' s 
site to signup a portal and to set the access security of the portal site. The invoicers' 
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site 216 also enrolls individual customers and provides for the entry of payment 
banking and customer information. This process can be performed manually by the 
customer or by pulling information from Microsoft Wallet or similar programs that 
exchange this information with the customer's workstation. In addition, the 
5 invoicer' s site will pass the customer's authentication information, for example the 
username/password pair, back to the summary agent . This authentication creates a 
security ID for customer account access to provide data for valid customers. 

In addition to a single portal model, the invoicer site may also allow a 
customer to choose multiple portal entries. For example, a customer may wish to 

10 have the option of going through multiple portals, such as AOL or YAHOO!. 

The invoicer site 216 fulfills the data summary request and handles error 
messages from summary agent portal 214. It passes graphics or XML to the portal, 
which includes summary data, and, at the same time, the invoicer's link for detailed 
data review. This utilizes the URL established during the enrollment process to fulfill 

15 these requests. Finally, the invoicer site 216 allows return to the summary agent 

portal 214 through, for example, through a popup window to display at the invoicer's 
site 216 or by utilizing frames. 

In the preferred embodiment, the "thin" portal model does not store any of the 
customer's information at the portal, neither payment information nor detailed invoice 

20 information. The customer is always sent to the invoicer to view detailed invoice 
information or execute payments. First, the invoicer enrolls with a portal banking 
server or with a presentation service. The invoicer first shows authentication 
parameters for communications with the presentations service and the invoicer. At 
the same time, the invoicer establishes URLs and summary server IDs to allow 

25 contact between the summary agent portal 214 and the invoicer site 216. The invoicer 
can also, at the same time determine its frequencies of updates to portal based on its 
billing cycle. Finally, the invoicer may also allow for banner ad management 
information at the portal with respect to the invoicer. 

As best seen in Figure 104, the enrollment process is described in more detail. 

30 In the enrollment process, the summary agent portal 214, such as YAHOO!, AOL, or 
Home Banking Site allows the customer to enroll at the portal by entering customer 
information and a username password pair. In addition, the customer may add e-mail 
information to allow the portal site to notify customer 212 of the receipt of a new bill 
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summary. The customer also may enter general banking information, payment 
sources including payment arrangements and invoicers the customer would like 
displayed. At the same time the customer can configure the information displayed by 
the invoicer, for example such as the page display, including limits, messages, and 
5 tolerances. Finally, the customer can allow publishing at other portals at the same 
time. 

Once the customer has been enrolled, the customer may also, at the same time, 
enter invoicer specific enrollment information either at the summary agent's or at the 
invoicer site 216. In the case of customer enrollment in the invoicer site 216, this 

10 information may be passed from the portal to the invoicer including customer 
information, e-mail information, payment source information, and payment 
arrangements. This information may be modified at the invoicer' s site 216 if it 
changes in the future. Once the finalized enrollment is made at the invoicer' s site, it 
returns customer information, such as an ID and pin code, to the portal agent 

15 summary 214. The customer 212 may also enroll at other invoicer sites based on 
invoicers selected from the list by the customer 212. 

The summary agent portal 214 puts the customer in the pending queue at the 
portal and sends confirmation to the customer via e-mail. When the confirmation is 
returned that the customer has received and opened the e-mail, it will activate the 

20 customer at the portal and the invoicer sites to allow the customer to review its 
summary bills. 

The payment information that the portal collects may then in turn be published 
to the other invoicer sites. As used herein, published to the invoicer site means that 
the information is sent to the invoicers so that the invoicers now have the payment 

25 information. 

The invoice presentation process of the present invention can best be 
understood by referring to Figure 105. First, at the invoicer site 216, invoicing is 
performed and detailed invoices are placed on the detailed invoice server. Summary 
information is copied from the detailed invoice server to a summary server, which 

30 includes, for example, invoice amounts, payment arrangements, and payment status. 
Summary data is then retrieved from each summary server at the invoicer including 
the invoice amount, payment arrangements and payment status. Customer 212 
utilizes the DYNAMIC INBOX to view the bill information at the summary agent. 
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When the customer is ready to review detailed information about each invoice, 
he is linked to the detail invoice and authentication is sent upon the transfer to the 
invoicer site 216. In the case of the "thin" portal model, these detailed records are not 
kept at the summary agent portaL In contrast using the "thick" portal model, changes 
5 may be made to the payment arrangements through the summary agent portal to the 
invoicer site 216 and passed out to the invoicer on the detailed invoice server. 

As best seen in Figure 106, once transferred to the invoicer' s site 216, the 
customer 212 may access through a payment processing engine 220 paying and 
updating its accounts, which will be described in more detail in Figures 1 12; 1 13 A 
10 and 1 13B, (what are these numbers) below. 

Turning to Figure 107, there is shown an outline of the preferred data model 
for the present invention. In the preferred embodiment, the summary agent portal 214 
includes detailed customer information and default customer payment source 
information. It also includes a default customer payment arrangements and invoicer 
1 5 information for the portal/invoicer association. This may include the invoicers' 
display and the billing summary information. Portal banner information and portal 
banner metrics and customer profile may also be stored at the summary portal agent 
214. 

At the invoicer site 216, complimentary customer information and the 
20 name/password pair for the customer. The invoicer site 216 further includes customer 
contact information and payment source information, payment arrangements and 
rules, and accounting information and history. In addition, it includes summary 
information such as the server identifiers and invoicer password and authentication 
for portal parameters and general portal information. Finally, the invoicer site 216 
25 may include invoicer banner information and invoicer banner metrics. 

An alternative embodiment of the present invention is the thick portal model. 
The distinction between thick and thin portal models is that in the thick portal model, 
payment information is contained at the portal site and then is published in turn to the 
invoicers. The dynamic consolidation functional model for a thick portal model is 
30 best shown in Figure 108. This embodiment differs from the embodiment model 

shown and discussed with respect to Figure 102 and the following critical parameters, 
payment information is stored at the portal and detailed invoice information may also 
be stored at the portal. 
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As best seen in Figure 109, there is shown a schematic representation of the 
enrollment portion of an automated electronic invoicing and payment consolidation 
system constructed according to present invention. Remote computer 400 accesses 
the portal administration web server for enrolling invoicers. Network 405 accesses 
5 web server, through either Internet, internal LAN, dialup. Invoicer enrollment 
application 410 that allows customer to enter in information about individual 
invoicers 

Page display 410 allows customer to enter information about invoicer, 
including URLs, graphics, validation fields, and logos. Application then stores 

10 information into database 430. 

Web server 420 at the portal hosts enrollment application. Database 430 
stores invoicer enrollment information. The database is also used to retrieve 
information about the list of valid invoicers, which the customer can select from when 
enrolling in this service. Remote computer 440 accesses the portal administration 

15 web server for enrolling customers. 

The Customer enrollment application 450 allows the customer to select which 
invoicers they would like to have displayed in their dynamic inbox. The application 
450 first reads from the database 430 to determine list of valid invoicers that can be 
displayed to the customer and retrieves invoicer information to complete enrollment 

20 (e.g. URL to pass customer for completion of enrollment at the invoicer). The 

application 450 then displays a list of these valid invoicers to the customer. When 
the customer selects the invoicer, the application 450 displays a list of fields that the 
customer must complete (e.g. username, password, account). These fields are 
invoicer specific and are also retrieved from the database 430. Once these fields are 

25 completed, the customer is passed to the invoicer enrollment application 540. The 
invoicer validation information is also passed in this transfer. The invoicer 
enrollment application is responsible for generating authentication information for 
access within the dynamic inbox. This authentication information is passed back to 
customer enrollment application 450 and then stored in the customer and 

30 authentication information database 480. 

Customer desktop payment information is shown in 460. The customer may 
have entered payment account information (e.g. checking account information, credit 
card information) and stored in a local database on their personal machine. Customer 
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may have entered information through an application like Microsoft Wallet. This 
information can then be passed to the invoicer enrollment application 540 through 
XML, OFX/IFX or other data publishing standard. 

Web server 470 at the portal hosts the customer enrollment application. 
5 Database 480 stores the customer enrollment and authentication information. 

Remote computer 500 accesses the invoicer administration web server for 
enrolling portals. The portal enrollment application 510 allows customer to enter in 
information about individual portals. The page display allows customer to enter 
information about portal, including identification and URLs. Application 510 then 
10 stores information into database 530. Web server 520 at the invoicer hosts the portal 
enrollment application. Database 530 stores portal enrollment information. The 
database is also used by the portal validation application 580 to verify that the portal 
passing control during customer enrollment is a portal that has been enrolled with 
invoicer. 

1 5 The invoicer enrollment application 540 accepts the request from the portal 

customer enrollment page 450 and calls the portal authentication application 560 to 
verify portal that the request originates from. Application 540 also generates 
authentication information for the customer and returns this authentication back to the 
portal customer enrollment application 450. Application 540 also stores this 

20 authentication information into a database 600 for future authentication on dynamic 
inbox. Application 540 also verifies that this customer is an EBPP customer at this 
invoicer by providing the customer authentication application 580 the fields and 
values entered at the portal. 

Authentication Data Generator 550 creates security information, encrypts this 

25 security information and stores this data into the Dynamic Consolidation 

Authentication database 600. It is called from the invoicer enrollment application 540 
and passes back the generated authentication information. 

Portal Authentication application 560 reads from the portal enrollment 
database 530 to determine the list of valid portals and their appropriate identifications. 

30 The application 560 is called from the invoicer enrollment application 540 that passes 
it the portal identification received on the request. This application takes this portal 
identification, checks it against this database, and validates its existence and proper 
identification. 
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Web server 570 at the invoicer hosts invoicer enrollment application. 
Customer Authentication application 580 reads from the invoicer' s EBPP database 
590 for the list of valid customers and accounts. It checks to make sure that this is a 
customer on EBPP and that the account is valid for this customer and that the 
5 customer has entered proper validation for accessing this account. 

The EBPP database 590 manages customers on this service, list of accounts, 
and validation information for customer to access specific accounts. 

Customer Authentication database 600 is used to store the security and 
validation data for customer that was generated by the authentication data generator 
10 550. It is used for validation when customer wants to display bills from the dynamic 
inbox. 

As can be understood, Enrollment could be done beginning at the invoicer site 
and the invoicer will display list of possible portals for customer enrollment. Control 
would then be passed to the portal to complete the enrollment process. In addition, 

15 desktop payment information 460 could be passed to the invoicers using a variety of 
standards, XML, OFX/IFX. The way in which this information is passed to the 
invoicers should not limit this patent. 

As best seen in Figure 110, there is shown a schematic representation of the 
dynamic display portion of an automated electronic invoicing and payment 

20 consolidation system constructed according to present invention. Remote computer 
440 accesses the portal display web server for enrolling invoicers. Network 710 
accesses web server, through either Internet, internal LAN, or dialup. Web server 720 
at the portal hosts the dynamic inbox application. 

The portal Page builder application 730 creates page for display of portal 

25 information to customer. This application constructs and outputs web html 

documents for display on the web server. It also accepts customer requests for 
display and navigation through the page and site. This application calls the bill 
summary page builder 740 to create the dynamic inbox section of the page for the 
customer. The portal application 730 passes the customer information obtained by the 

30 customer login into the portal site to the bill summary page builder 740. 

Bill summary page builder application 740 constructs the bill summary for the 
customer on the portal's page. The page builder builds the dynamic inbox for a 
customer upon request by first authenticating through the customer authentication 
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application 745 that validates that this is a valid customer. It also retrieves the stored 
security tokens for the customer to pass to the invoicer data server 765 in encrypted 
form through a secure link. The invoicer data server 765 then confirms the 
customer's validation information against its customer authentication database 600. 
5 The bill summary page builder also retrieves from the customer authentication 
application 745 the list of invoicers that the customer chooses to display in their 
dynamic inbox. The bill summary page builder then calls the invoicer authentication 
application 750 to validate the invoicers selected by the customer and also retrieves 
the invoicer URL information for building the invoicer links in the dynamic inbox. 

10 The bill summary page builder passes a series of requests to the invoicer data 

server 765 through a secure link for the customer, including security tokens for 
validation, invoicer, and accounts, and type of data requested. After validating the 
customer and the invoicer, the invoicer data server 765 then returns back the 
requested data to the bill summary page builder through a secure link. 

15 Invoicer authentication application 750 validates that the invoicers sent from 

the bill summary page builder are valid invoicers by checking against the invoicer 
authentication database 430. It also retrieves other invoicer information including 
URLs from the invoicer authentication database 430. 

Customer preferences application 760 allows customer to configure the 

20 display of web pages from the portal. The customer is able to select how and what 
items they would like to have displayed on their page. The customer can also 
configure how bills are displayed for dynamic inbox in this application by selecting 
display changes based upon certain values. For example, the customer could 
configure the application to change the color of the invoicer line to red if the date due 

25 has exceeded the current day. This application will store customer's preferences and 
retrieve them upon page display by the customer. 

Database 770 stores customer page preferences. This database is used for 
storage of those preferences and its data is retrieved by the customer preferences 
application 760 for determining the customer's preferences when displaying the page. 

30 Invoicer data server 765 is responsible for validating the request from the bill 

summary page builder 740 and returning the appropriate data or error message to this 
application. 
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The portal validation application 772 is part of the invoicer data server 765 
that first validates that portal making the request is a valid portal by checking against 
the portal enrollment database 530. Account validation application 775 is part of the 
invoicer data server 765 that validates the customer's account and identification is 

5 valid by checking the security tokens against the customer authentication database 
600. The application decrypts the security token and compares this decrypted token 
with the customer's token stored in the database. 

The Request Translator application 780 is part of the invoicer data server 765 
and passes the customer's request to the appropriate server for retrieving the 

10 necessary data. XML server 790 retrieves information about the customer's bill data 
for this account and packages it into an XML format that is returned to the invoicer 
data server 765. It retrieves this information through the invoicer summary server 
application 820 that retrieves this information from the invoicer' s system either at the 
time of the request or in a batch mode. 

15 Graphics Server 800 retrieves information about the customer's bill data for 

this account and packages it into a graphic format (GIF, or other graphic format) and 
returns it to the invoicer data server 765. It retrieves this information through the 
invoicer summary server application 820 that retrieves this information from the 
invoicer's system either at the time of the request or in a batch mode. 

20 Generic or specific format server 810 retrieves information about the 

customer's bill data for this account and packages it into in specified format. This 
format can be IFX, OFX ? EDI, or other specified format and these servers will handle 
the packaging of this information to be passed back to the invoicer data server 765. It 
retrieves this information through the invoicer summary server application 820 that 

25 retrieves this information from the invoicer's system either at the time of the request 
or in a batch mode. 

Invoicer summary server application 820 receives request from the format 
servers and retrieves this invoicer information from the invoicer summary database 
830. The invoicer summary database is populated by the invoicer either at the time of 

30 the request or through batch processing. Alternatively, the invoicer summary server 
could retrieve the information directly from the invoicer systems through some 
interface or specified database stored procedure. 
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Database 830 stores invoicer summary information that the invoicer's system 
either populates at the time of the request from the invoicer summary server 
application or is updated on a periodic basis from the invoicer systems. 

Turning to Figure 111, there is illustrated the current process used for paper 
invoice payment and automated invoice payment using a third party service provider. 

In the case of the paper invoice process, an invoicer 10 prepares a paper 
invoice 12, which is sent via mail to customer 20. After verifying that the invoice is 
correct customer 20 prepares a paper check 22 and returns the paper check 22 to 
invoicer 10. Invoicer 10 then credits the account of customer 20 and submits check 
22 with its other business receipts to invoicer bank 30. Invoicer bank 30 then 
interacts with customer bank 40 via the well-known ACH network to demand the 
funds from customer's checking account and deposit those funds into the invoicer's 
checking account. This interaction follows a conventional, well known process 
represented by 32, 42. 

As discussed above, some period may elapse before invoicer 10 receives 
check 22 from customer 20. This process can be expedited somewhat if the check is 
sent directly from customer 20 to invoicer bank 30. This "lock box" process takes 
place through the use of a post office box address on the invoice, which sends the 
check 22 to invoicer bank 30 even though the address on the invoice 12 may show the 
name of invoicer 10. In this modified process, after receiving check 22, invoicer bank 
30 will still go through the ACH network 32, 42 before funds are credited to invoicer's 
account. 

In an attempt to automate this process, third party service providers 54 have 
entered the scene. Here invoicer 10 transmits an electronic data stream 14 to service 
provider 54 containing all of the information that normally is contained in a paper 
invoice. There is then an electronic communication 52 between service provider 54 
and customer 20 for the purpose of notifying customer 20 of the pending charge and, 
in some cases, allowing the customer to approve of the charge against its accounts. 
Service provider 54 then transmits payment authorization 52 to customer bank 40. At 
the same time, service provider 54 may also transmit a message 56 to invoicer 10 with 
notification of the payment authorization 52. 

After receiving authorization 52, customer bank 40 then sends payment to 
invoicer bank 30 through conventional channels. 
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The non-bank service provider 54 may also be granted access to the ACH 
network to direct draft via PPD customer bank 40 on behalf of customer 20, In this 
case, service provider 54 may receive funds from the customer into the service 
provider checking account and then disperse those funds to invoicer 10. 
5 As can be seen from the complexity of Figure 111, both the conventional 

paper invoice process and the third party service provider process are cumbersome, 
and time/labor intensive. 

As best seen in Figure 112, a method for electronic invoicing and paying is 
shown constructed according to the present invention. The method starts with the 

10 electronic presentment 50 of an invoice to customer 20. It should be understood that 
the term "presentment" as used herein does not include the specialized definition 
normally associated with commercial paper, i.e., the production of a negotiable 
instrument to a drawee. Rather, the term refers to providing via electronic means an 
"invoice" containing at least the same customer billing data typically included on a 

1 5 paper invoice. This electronic presentment may take place through the use of an 
Internet website, a bank ATM machine or through the use of a stand alone kiosk. 

In a preferred embodiment, the invoice would also include, in addition to 
normal billing data, a request for payment instructions. This request provides the 
customer the opportunity to select either the bank account from which the invoice will 

20 be paid, or it provides the customer with the option to pay via a debit card, credit card, 
ATM, stored value card or some source of funds. 

The invoice would include billing data such as the customer name, address, 
account number and e-mail address. The invoice may further include bill data 
typically included with a paper invoice to include the period covered by the invoice, a 

25 detail of the goods/services covered by the invoice, a total amount due and a payment 
due date. 

In addition to the typical invoice information, the electronic invoice 
presentment may also include customer notices relating to changes in credit terms and 
the like. Invoicer 10 may also include sales and promotional materials informing 
30 customer 20 of new products or sales on existing products. 

After electronic invoice presentment 50, the customer provides an electronic 
authorization 52 to the invoicer 10 permitting customer's account to be charged. This 
step eliminates the time and expense of preparing and mailing a paper check. Thus, 
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invoicer 10 could be in a position to debit customer's bank account in as little as one 
day as opposed to the period required to receive a paper check 22. 

The information included in this electronic authorization could include the 
invoice account number and an associated customer payment account. In a preferred 
embodiment, both these items of information are submitted simultaneously with the 
authorization. When pre-arranged instructions are made, this information does not 
need to re-submitted each time. 

Prior to providing the authorization for payment, customer 20 is provided with 
a number of options for changing the payment instructions to create modified 
payment instruction 52a. These modifications can range from no modification at all 
in accepting all the payment terms contained in the presentment. Alternatively, 
customer 20 may be provided with any combination of the following options: 

1) The customer may pay less than the amount due on the invoice for 
either unspecified reasons or for a specific reason such a dispute 
concerning a line item contained on the invoice. 

2) The customer may elect to pay more than the amount due on the 
invoice. 

3) The customer may elect to make a special payment, for example, an 
extra principal payment on a loan. 

4) The customer may elect to change the date that the payment, via 
electronic transfer, will take place, provided that such date has not 
already passed. 

5) The customer may change the source of funds for the payment, i.e., 
from a primary checking account to a pre-authorized credit card. 

Making any of these changes discussed above requires that the customer be 
authorized to do so by the invoicer. 

The method described above may be carried out by an automated billing 
system depicted schematically in Figure 1 13A which provides remote customer 
review of automated billing from an invoicer to include: (a) invoice presentation 
electronics 60 adapted to present customer billing data in request for payment 
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instructions related to automated billing, and (b) an electronic customer authorization 
interface 84. 

The customer interface receives customer billing data and request for payment 
instructions from the invoicer presentation electronics and provides those items to the 
customer. The interface also receives customer payment instructions in response to 
the request for payment instructions and transmits those instructions from the 
customer to the invoicer. 

The invoice presentment electronics 60 may further include a control system 
62 and first communication electronics 64. These components typically are located in 
an invoicer controlled facility. 

At a customer facility, the system includes a remote authorization terminal 80 
having second communication electronics 82 adapted to communicate with first 
electronic communications 64. Control system 62 coordinates the generation of the 
electronic invoice 50 containing at least all the billing information normally included 
on a traditional paper invoice along with a request for payment instructions. Control 
system then oversees the submission of that information from the first communication 
electronics 64 to the second communication electronics 82 for review by the 
customer. 

Remote authorization terminal 80 is adapted to present the billing data to a 
customer and to an appropriate response relating to the billing data from the customer. 
The response indicates acceptance of the billing data without change for automated 
payment or modification of the billing data as described above. The customer 
interface 84 is further adapted to transmit this information to invoice presentment 
electronics 60. 

The components of this system may be configured in a number of ways. For 
example, the customer accessible site may reside in an Internet website provided by 
invoicer for receiving the billing data and payment instructions from the customer. 
The website will be accessible from the customer electronic authorization interface 
84. In this instance, the customer authorization interface 84 would include an Internet 
browser for accessing the customer accessible site. 

Other alternatives for the electronic customer authorization interface include 
an automated teller machine (ATM), a remote kiosk, a personal computer, an 
interactive television device, or a telephone. 
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In the case of a telephone, the electronic customer authorization interface 84 
could include either a well-known touch-tone telephone or a screen-based telephone. 

In another embodiment, the electronic customer authorization interface 84 is a 
digital computer with the billing data and the payment request instructions presented 
by e-mail to the customer with an e-mail reply for relaying customer payment 
instructions 52 to the invoice presentation electronics 60. The electronic customer 
authorization interface 84 could also include a display for presenting billing data and 
the request for payment instructions along with a customer actuable input for 
receiving customer payment instructions. 

In addition to the visual display, the electronic customer authorization 
interface 84 could further include audio electronics 85 and a speaker 86 for presenting 
billing data and request for payment instructions to the customer. In this embodiment, 
the customer actuable input for receiving customer payment instructions may also 
feature a customer-spoken input. 

The electronic customer authorization interface 84 may also be adapted to 
allow a customer to poll the invoice presentment electronics 60 to receive billing data 
and payment request instructions. 

The automated billing system of the present invention includes submitting 
billing data from an invoicer to a customer for remote customer review and 
acceptance/modification and the transmission of those items to the invoicer. The 
billing information 50 that may be submitted to the customer includes any 
combination of the following items: 

• payment due date 

• amount due 

• detail of goods/services provided during a billing period 

• late charges 

• account information 

• customer information to include customer name, customer address, and 
customer account identifier (the account identifier could include a 
customer number and/or an account number) 

• invoice identifier, e.g., invoice number 

• line item disputes 

• multiple invoice payments 
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The invoice presentment electronics 60 may include a memory device to store 
invoice information relating to customer bills and account information relating to 
financial institutions associated with the customer. That is, the customer may have 
the option of selecting from a number of accounts a specific account from which 
funds are drafted to pay the invoice. 

The memory device and the invoice presentment electronics 60 may also 
include information relating to a pre-authorized payment instruction for automated 
payment of the billing amount set out in the billing information from an account set 
out in the account information. If pre-authorized payment instructions are used, the 
request for payment instructions 50 originating in the invoice presentment electronics 
60 may query the customer for acceptance of those instructions with or without 
modification. To accomplish such a modification, the customer authorization 
interface 84 may further include an editor for modifying the pre-authorized payment 
instructions. 

The overall operation of the present invention can best be understood by 
referring to Figure 1 13B. The invoicer's customer can access the system through any 
remotely attached computing device 101 and communicates with the invoicer systems 
through a public or private network 102. A web server or communications processor 
of some kind 103 manages on-line communications between the customer and 
application systems that allow the customer to begin the provisioning process. The 
customer is presented electronically data input forms to complete by a provisioning 
application program 104 which also may validate whether the data input by the 
customer is valid according to the invoicer's records as contained in the Legacy 
systems. After determining whether customer and financial account records are 
accurate, the invoicer activates the customer for electronic invoice presentment and 
remittance. 

An electronic mail message or traditional letter may be sent to the customer 
with information that allows the customer to access the system, such as an account 
number and/or password. 

During the next invoicing cycle for this customer, appropriate data, such as 
Legacy print data and Legacy automatic payment 106 is acquired. Legacy print data 
is data that would normally be sent to a printer to prepare customers' invoices on 

29910 26 



paper. Legacy automatic payment data are records that are typically created by the 
invoicer that allow the invoicer to initiate payment based on pre-authorized 
arrangements with the customer. Payment records would include those formatted for 
automatic funds transfer from checking or savings accounts (ACH format data), debit 
5 transactions to credit cards, debit cards, or stored value cards. Files intended for 
transfer to ATM networks are also anticipated. 

In acquiring the data for the product, Legacy data is sorted, parsed, extracted 
by an application program 107 and appropriate control data is maintained for 
reporting on operations. An application program 108 loads data into a relational 

10 database 109 for monthly processing. In the preferred embodiment, two separate 
computers may be used for additional security over sensitive financial data such as 
account numbers or authorization codes. As a further security measure, the invoicer 
may choose to configure the product using a computer 1 10 located behind the 
invoicer's firewall security device and connected by a secured network 1 1 1 to the web 

1 5 server hosting computer 112. 

Invoice presentment data and subsets of data on financial arrangements are 
made available for presentment by transfer of data using immediate transfer, for 
example by way of an encrypted, remote stored procedure within the database 109 or 
by a batch transfer. 

20 Once data to be made available electronically has been accurately loaded to 

the web server database 1 13, an application program 114 sends an electronic mail 
message to the customer announcing the availability of the monthly invoice and 
providing some summary of data. Since electronic mail account data may be invalid 
or services might be otherwise inoperative, the application program 1 14 is adapted to 

25 prepare data to be sent by the US Postal Service, fax or other means. A front-end 
processor 115 contains a template necessary to present the invoice and default 
payment arrangements 1 16 in the manner that the invoicer desires. The web server 
103 hosts an interactive session in which the customer accesses their invoice. The 
customer may choose to modify pre-arranged payment arrangements. As an example, 

30 the customer may change the amount to pay, the date for payment and changing the 
source of funds for the payment, from a personal checking account to another 
invoicer-approved source, such as a credit card. These arrangements 114 are stored 
on the web server database 113. 
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In the preferred embodiment, the customer could also use a telephone 117 
connected to a network 102 and a PBX telephone processing switch 1 18 to pass data 
to and from a voice response unit 119. The customer could call into hear information 
about his invoice and signal changes to pre-existing arrangements, either through 
5 touch-tone entry or speech recognition. These changes are processed by the front end 
processor 115 and recorded in the data base just like remote-computer-based entries. 

On each day that the invoicer transfers payment data to banks or financial 
transaction processing services, an application program 120 is executed to identify 
customers in the web server database 113 that have payments scheduled. Data from 

1 0 the web server is transferred for processing on the second computer 110 and 

combined with the data containing the pre-authorized, payment arrangements, which 
was initially stored in the relational database 109. Based on the customer's 
instructions, records are modified or might be deleted and recreated if a change in 
funding source is requested. Data is then formatted to interface back the invoicer' s 

15 Legacy systems 121, for example, simulating the normal file format for the invoicer' s 
lockbox processing. 

Data 122 is transferred to the invoicer' s bank or to a third party that processes 
financial transactions. An application program 123 records those instances when a 
customer's data within a processing batch is returned for insufficient funds or 

20 incorrect account data so that the correct payment history for a customer can be 
maintained. 

The security provisions of the product allow an exclusively invoicer-focused 
delivery of electronic invoice presentment and payment arrangements. Although the 
preferred embodiment anticipates that an invoicer may choose to outsource web 

25 server hosting or web server and remittance processing to an outside company on 
behalf of the invoicer, the service to customers would be provided so that the 
customer would not normally be aware that the invoicer was not actually operating 
the product directly. 

Certain modifications and improvements will occur to those skilled in the art 

30 upon a reading of the foregoing description. By way of example, Figure 103 shows 
enrollment starting at the invoicer whereas as to create tokens, representing a name 
and password pair, and authentication information that customer initially recorded, 
but the present invention may also begin enrollment at the summary agent or the 
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portal. Also, as used herein, the "invoicer" may also include an Accounts Payable 
site, which retrieves its information from more than one sub-invoicer and combines 
this information into a single invoice first. For example, a local telephone company 
may put together sub-invoices from itself, a separate long distance carrier and an 
Internet DSL service. It should be understood that all such modifications and 
improvements have been deleted herein for the sake of conciseness and readability but 
are properly within the scope of the following claims. 
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